FIG. 1 A: STRUCTURE OF AN INDOC TOOL 
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FIG. 1 B: EXAMPLE OF AN INDOC TOOL 
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FIG. 3: INDOC OPERATIONS 
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FIG. 4: EXPERIENCE SHARING INTERFACES 



Jo we reduce costs in this sti 



>How can we increase the speet 
adoption of the scheme? - Host c 



a Howdo wereduce costs in this step? - 

> How can we increase the speed in 
adoption of the scheme? - mst sawsm 

> How car we improve feedback cycles? 



Sfou^fTQtp Concerns 



t: Rohit Sinha; Date: 05/04/01 If we can plan well ahead and estimate cc 



Share you e Concerns 



(Response By |Name Surname 



FIG. 5: EXAMPLE OF INDOC OPERATIONS 
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FIG. 6A: EXAMPLE OF KNOWLEDGE SHARING AT THE 'STRUCTURE LEVEL' 
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FIG. 6B: EXAMPLE OF KNOWLEDGE SHARING AT THE 'CONTENT LEVEL' 

lensions of concern 
ved from the insight 
architecture j 



Sharing and retrieving 
knowledge fragments which 
get embedded within the 
specific content cluster 



10/25 



FIG. 7: DISTINCT SHARING LAYERS BASED ON OUTCOME LEVELS/ PERSPECTIVES 
FOR ANY ORGANIZATION 

7.1: Layers 




7.2: Content Sharing in each Layer 



User 


Knowledge 
Encounter Map 




< 


■ f "N / — N s- Corresponds to 

•^^^ 1 1 ^^^^K^JK /^n. y\ CH ) — v_ outcome level 1 

^ LlZLr \™/ 










■— 1 / N Corresponds to 
|_!Lr — outcome level 2 






"~" — -—■ 1 |T U V""^ Corresponds to 

I ^ v!y^y^\ JL outcome level 3 

""""" -*/chU */chV^~ 







IT: InDoCTool 
CH: Content Hub 



1 1/25 



FIG. 8: BASIS FOR KNOWLEDGE FRAGMENT SHARING PROTOCOL 
8.1: Dimensions of Concern 
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FIG. 9: LAYERED APPROACH TO IDENTIFY KNOWLEDGE SHARING PROTOCOL 
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FIG. 9.1 
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FIG. 1 0: FUNCTIONS OF THE CONTENT HUB 
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FIG. 1 1 : SPECIALIZED INDOC NET EMBODIMENTS 
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^S**** Insight Question Responses 
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FIGURE 1 2: INTELLIGENT CONTENT AGENTS: AGENT CLASS - INQUITREE: TOOL 
DESCRIPTION "WHAT IF" 
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FIGURE l 3: RADAR METAPHOR TOOL (EMBODIMENT COMPETITOR RADAR) 
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FIGURE 14 A : KNOWHOW DISTRIBUTION IN COMMUNITY OF PRACTICE 
Each structure set representing a knowledge transfer protocol 
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FIGURE 1 4 B: INTELLIGENT CONTENT HUBS BASED ON THE SHARING LAYERS 
DESCRIBED ABOVE 
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